In many multitier data processing architectures, client or user computing systems may access a backend data processing system (e.g., a database system) by way of an intermediate server or processing system. To access the backend processing system, a user of a client system, by way of an application executing on the client system, may request a communication connection with the backend processing system via the intermediate system, engage in whatever access is necessary with the backend system, and then close the connection until the time that another connection is required. Presuming the backend processing system is a database system, the amount of time consumed by the creation of a connection between the application and the backend processing system may exceed the amount of time used to execute the actual database transaction supported by the connection by a factor of a hundred, a thousand, or more. As a result, system designers have sought to reduce or eliminate unnecessary connection and reconnection operations to streamline the use of backend processing systems.
To that end, connection pools have become an oft-used tool in communicatively coupling a user of a client system with a backend processing system. Generally, a connection pool is a group of connections established between the intermediate system and the backend processing system that are reused multiple times and shared by the users to access the backend processing system, thus greatly reducing unnecessary reconnection operations. To maintain the connections for a connection pool, all of the connections are typically created for a single generic or “technical” user not specifically associated with any of the actual users of the client system. Each of the connections may then be provided to the actual users on an as-needed basis without repeatedly closing and recreating the connections. Such a connection pool is often termed a “homogeneous connection pool,” given the use of the single technical user to create and maintain the connections.
As a result of the use of a homogeneous connection pool, the backend processing system is typically aware of only the identity of the technical user, not the actual users of the client systems. Accordingly, without knowing which actual user is currently engaging the backend processing system, support for user authentication, access security for particular datasets, audit trails, and other organizational and governmental functions is complicated. To address this issue, other types of connection pools, such as a “pool-of-pools” (involving the creation of a homogeneous connection pool for each of the actual users) and heterogeneous connection pools (involving the creation of multiple connections, each based on credentials of an actual user), have been employed. However, while these alternative pooling systems may facilitate support for security and auditing functions at the client device or application, other complications often result, such as a lack of sharing of each connection among the actual users, which may in turn cause the creation and teardown of a number of connections well beyond that of a homogeneous connection pool to facilitate concurrent access among the users of the client systems.